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1. Overview 


This document is informational and is NOT NORMATIVE on any aspect of 
SIP. 


This document contains test messages based on the current version 
(2.0) of the Session Initiation Protocol as, defined in [RFC3261]. 
Some messages exercise SIP’s use of the Session Description Protocol 
(SDP), as described in [RFC3264]. 


These messages were developed and refined at the SIPIt 
interoperability test events. 


The test messages are organized into several sections. Some stress 
only a SIP parser, and others stress both the parser and the 
application above it. Some messages are valid, and some are not. 
Each example clearly calls out what makes any invalid messages 
incorrect. 


This document does not attempt to catalog every way to make an 
invalid message, nor does it attempt to be comprehensive in exploring 
unusual, but valid, messages. Instead, it tries to focus on areas 
that have caused interoperability problems or that have particularly 
unfavorable characteristics if they are handled improperly. This 
document is a seed for a test plan, not a test plan in itself. 


The messages are presented in the text using a set of markup 
conventions to avoid ambiguity and meet Internet-Draft layout 
requirements. To resolve any remaining ambiguity, a bit-accurate 
version of each message is encapsulated in an appendix. 


2. Document Conventions 
This document contains many example SIP messages. Although SIP is a 
text-based protocol, many of these examples cannot be unambiguously 


rendered without additional markup due to the constraints placed on 
the formatting of RFCs. This document defines and uses the markup 
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defined in this section to remove that ambiguity. This markup uses 
the start and end tag conventions of XML but does not define any XML 
document type. 


The appendix contains an encoded binary form of all the messages and 
the algorithm needed to decode them into files. 


2.1. Representing Long Lines 


Several of these examples contain unfolded lines longer than 72 
characters. These are captured between <allOneLine/> tags. The 
single unfolded line is reconstructed by directly concatenating all 
lines appearing between the tags (discarding any line feeds or 
carriage returns). There will be no whitespace at the end of lines. 
Any whitespace appearing at a fold-point will appear at the beginning 
of a line. 


The following represent the same string of bits: 
Header-name: first value, reallylongsecondvalue, third value 


<allOneLine> 

Header-name: first value, 
reallylongsecondvalue 

, third value 
</allOneLine> 


<allOneLine> 
Header-name: first value, 
reallylong 
second 
value, 
third value 
</allOneLine> 


Note that this is NOT SIP header-line folding, where different 
strings of bits have equivalent meaning. 


2.2. Representing Non-printable Characters 
Several examples contain binary message bodies or header field values 
containing non-ascii range UTF-8 encoded characters. These are 


rendered here as a pair of hexadecimal digits per octet between 
<hex/> tags. This rendering applies even inside quoted-strings. 
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The following represent the same string of bits: 


Header-name: value one 
Header-name: value<hex>206F6E</hex>e 


The following is a Subject header field containing the euro symbol: 
Subject: <hex>E282AC</hex> 

2.3. Representing Long Repeating Strings 
Several examples contain very large data values created with 
repeating bit strings. Those will be rendered here using <repeat 
count=some_integer>value</repeat>. As with <hex>, this rendering 
applies even inside quoted strings. 
For example, the value "abcabcabc" can be rendered as <repeat 
count=3>abc</repeat>. A display name of "1000000 bottles of beer" 


could be rendered as 


To: "l«repeat count=6><hex>30</hex></repeat> bottles of beer" 
<sip:beer.example.com> 


A Max-Forwards header field with a value of one google will be 
rendered here as 


Max-Forwards: l<repeat count=100>0</repeat> 
3. SIP Test Messages 
3.1. Parser Tests (syntax) 
3.1.1. Valid Messages 
3.1.1.1. A Short Tortuous INVITE 
This short, relatively human-readable message contains: 
o line folding all over. 
O escaped characters within quotes. 
o an empty subject. 


o LWS between colons, semicolons, header field values, and other 
fields. 


o both comma separated and separately listed header field values. 
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o a mix of short and long form for the same header field name. 
o unknown Request-URI parameter. 
o unknown header fields. 


o an unknown header field with a value that would be syntactically 
invalid if it were defined in terms of generic-param. 


o unusual header field ordering. 

o unusual header field name character case. 

o unknown parameters of a known header field. 

O a uri parameter with no value. 

o a header parameter with no value. 

o integer fields (Max-Forwards and CSeq) with leading zeros. 

All elements should treat this as a well-formed request. 

The UnknownHeaderWithUnusualValue header field deserves special 
attention. If this header field were defined in terms of comma- 
Separated values with semicolon-separated parameters (as would many 
of the existing defined header fields), this would be invalid. 
However, since the receiving element does not know the definition of 
the syntax for this field, it must parse it as a header value. 


Proxies would forward this header field unchanged.  Endpoints would 
ignore the header field. 
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Message Details : wsinv 


INVITE sip:vivekgGchair-dnrc.example.com;unknownparam SIP/2.0 


TO 
sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n 
from : "J Rosenberg \\\"" <sip: jdrosen@example.com> 


f 
tag = 98asjd8 
MaX-fOrWaRdS: 0068 
Call-ID: wsinv.ndaksdj@192.0.2.1 
Content-Length 2-150 
cseq: 0009 
INVITE 
Via : SIP / 2.0 
/UDP 
192.0.2.2;branch=390skdjuw 
S : 
NewFangledHeader: newfangled value 
continued newfangled value 
UnknownHeaderWithUnusualValue: ;;,,;;,; 
Content-Type: application/sdp 
Route: 
<sip:services.example.com; lr; unknownwith=value; unknown-no-value> 
v: SIP / 2.0 / TOP spindle.example.com ; 
branch = z9hGAbK9ikj8 , 
SIP / 220 / UDP 192.168.255.111 ; branch- 
z9hG4bK30239 
m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam = 
newvalue ; 
secondparam ; q = 0.33 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.3 
s=- 

c=IN IP4 192.0.2.4 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 
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3.1.1.2. Wide Range of Valid Characters 


This message exercises a wider range of characters in several key 
syntactic elements than implementations usually see. In particular, 
note the following: 


o The Method contains non-alpha characters from token. Note that % 
is not an escape character for this field. A method of IN%56ITE 
is an unknown method. It is not the same as a method of INVITE. 


o The Request-URI contains unusual, but legal, characters. 


o A branch parameter contains all non-alphanum characters from 
token. 


o The To header field value’s quoted string contains quoted-pair 
expansions, including a quoted NULL character. 


o The name part of name-addr in the From header field value contains 
multiple tokens (instead of a quoted string) with all non-alphanum 
characters from the token production rule. That value also has an 
unknown header parameter whose name contains the non-alphanum 
token characters and whose value is a non-ascii range UTF-8 
encoded string. The tag parameter on this value contains the 
non-alphanum token characters. 


o The Call-ID header field value contains the non-alphanum 
characters from word. Notice that in this production: 


* % is not an escape character. It is only an escape character 
in productions matching the rule "escaped". 


* " does not start a quoted string. None of ',"or " imply that 
there will be a matching symbol later in the string. 


* The characters []{}()<> do not have any grouping semantics. 
They are not required to appear in balanced pairs. 


o There is an unknown header field (matching extension-header) with 
non-alphanum token characters in its name and a UTF8-NONASCII 
value. 


If this unusual URI has been defined at a proxy, the proxy will 
forward this request normally. Otherwise, a proxy will generate a 
404. Endpoints will generate a 501 listing the methods they 
understand in an Allow header field. 
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Message Details : intmeth 


<allOneLine> 

!interesting-Method0123456789 *+".%indeed'” 
sip:1_unusual.URI™ (to-be! sure) &isn’t+it$/crazy?,/;;* 
:&itthas=1,weird! *pas$wo~d_too. (doesn't-it) 

@example.com SIP/2.0 

</allOneLine> 

Via: SIP/2.0/TCP hostl.example.com;branch=z9hG4bK-.!%66* +""" 
<allOneLine> 

To: "BEL: \<hex>07</hex> NUL: \<hex>00</hex> DEL: \<hex>7F</hex>" 
<sip:1_unusual.URI™ (to-be! sure) &isn’t+it$/crazy?,/;;* 
@example.com> 


</allOneLine> 

<allOneLine> 

From: tokenl^" token2’+_ token3*%!.- <sip:mundane@example.com> 
;fromParam’’~+*_!.-%= 


"<hex>D180DO0BODOB1DOBED182D0B0D18ED18 9DOB8D0B9</hex>" 

;ztag= token"1"+"*%1-. 

</allOneLine> 

Call-ID: intmeth.word%ZK-!.*_+’ @word*”) (><:\/"] [?}{ 

CSeq: 139122385 !interesting-Method0123456789_*+*.%indeed’ ~ 
Max-Forwards: 255 


<allOneLine> 
extensionHeader-!.%*+ "'^: 
<hex>EFBBBFESA4A7E5819CE99BBB</hex> 
</allOneLine> 


Content-Length: 0 


3.1.1.3. Valid Use of the % Escaping Mechanism 


This INVITE exercises the % HEX HEX escaping mechanism in several 
places. The request is syntactically valid. Interesting features 
include the following: 


o 
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The request-URI has sips:user@example.com embedded in its 


userpart. What that might mean to example.net is beyond the scope 


of this document. 
The From and To URIs have escaped characters in their userparts. 


The Contact URI has escaped characters in the URI parameters. 
Note that the "name" uri-parameter has a value of "value%41", 
which is NOT equivalent to "valueA". Per [RFC3986], unescaping 
URI components is never performed recursively. 
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A parser must accept this as a well-formed message. The application 
using the message must treat the % HEX HEX expansions as equivalent 
to the character being encoded. The application must not try to 
interpret % as an escape character in those places where % HEX HEX 
("escaped" in the grammar) is not a valid part of the construction. 
In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, 


SIPS-URI, and Reason-Phrase. 


Message Details : esc01 


INVITE sip:sips$3Auser$40example.comGexample.net SIP/2.0 
To: sip:%75se%72@example.com 
From: «sip:I$20have$20spacesGexample.net»;tag-938 
Max-Forwards: 87 
i: esc01.239409asdfakjkn23onasd0-3234 
CSeq: 234234 INVITE 
Via: SIP/2.0/UDP host5.example.net;branch-z9hG4bKkdjuw 
C: application/sdp 
Contact: 

<sip:cal%6Cer@host5.example.net; %6C%72;n%61lme=v%611ue%25%34%31> 
Content-Length: 150 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.1 
s-- 

c=IN IP4 192.0.2.1 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 
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3.1.1.4. Escaped Nulls in URIs 


This register request contains several URIs with nulls in the 
userpart. The message is well formed - parsers must accept this 
message. Implementations must take special care when unescaping the 
Address-of-Record (AOR) in this request so as to not prematurely 
shorten the username. This request registers two distinct contact 
URIs. 


Message Details : escnull 


REGISTER sip:example.com SIP/2.0 

To: sip:null-%00-null@example.com 

From: sip:null-$00-nullGexample.com;tag-839923423 
Max-Forwards: 70 

Call-ID: escnull.39203ndfvkjdasfkq3w4otrqladsfdfnavd 
CSeq: 14398234 REGISTER 

Via: SIP/2.0/UDP host5.example.com;branch-z9hG4bKkdjuw 
Contact: «sip:$008host5.example.com» 

Contact: <sip:%00%00@host5.example.com> 

L:0 


3.1.1.5. Use of % When It Is Not an Escape 


In most of the places % can appear in a SIP message, it is not an 
escape character. This can surprise the unwary implementor. The 


following well-formed request has these properties: 


o The request method is unknown. It is NOT equivalent to REGISTER. 


o The display name portion of the To and From header fields is 
"$2$45". Note that this is not the same as %ZE. 


o This message has two Contact header field values, not three. 
<sip:alias2@host2.example.com> is a C%6Fntact header field value. 


A parser should accept this message as well formed. A proxy would 


forward or reject the message depending on what the Request-URI meant 
to it. An endpoint would reject this message with a 501. 
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Message Details : esc02 


RES47IST%45R sip:registrar.example.com SIP/2.0 

To: "$2$45" <sip:resource@example.com> 

From: "$2$45" <sip:resourcefexample.com>;tag=f232jadfj23 
Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf 

Via: SIP/2.0/TCP host.example.com;branch=z9hG4bkK209%fzsnel234 
CSeq: 29344 RES47ISTS45R 

Max-Forwards: 70 

Contact: <sip:aliasl@hostl.example.com> 

C$6Fntact: <sip:alias2@host2.example.com> 

Contact: <sip:alias3@host3.example.com> 

1s 0 


3.1.1.6. Message with No LWS between Display Name and < 


This OPTIONS request is not valid per the grammar in RFC 3261 since 
there is no LWS between the token in the display name and « in the 
From header field value. This has been identified as a specification 
bug that will be removed when RFC 3261 is revised. Elements should 
accept this request as well formed. 


Message Details : lwsdisp 


OPTIONS sip:user@example.com SIP/2.0 

To: sip:user@example.com 

From: caller<sip:caller@example.com>; tag=323 
Max-Forwards: 70 

Call-ID: lwsdisp.1234abcd@funky.example.com 

CSeq: 60 OPTIONS 

Via: SIP/2.0/UDP funky.example.com;branch-z9hG4bKkdjuw 
1: 0 


3.1.1.7. Long Values in Header Fields 


This well-formed request contains header fields with many values and 
values that are very long. Features include the following: 


o The To header field has a long display name, and long uri 
parameter names and values. 


o The From header field has long header parameter names and values, 
in particular, a very long tag. 


o The Call-ID is one long token. 
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Message Details : longreq 


INVITE sip:user@example.com SIP/2.0 

<allOneLine> 

To: "I have a user name of 

<repeat count=10>extreme</repeat> proportion" 
<sip:user@example.com: 6000; 

unknownparaml=very<repeat count=20>long</repeat>value; 
longparam<repeat count=25>name</repeat>=shortvalue; 

very<repeat count=25>long</repeat>ParameterNameWithNoValue> 
</allOneLine> 

<allOneLine> 

F: sip: 

«repeat count=5>amazinglylongcallername</repeat>@example.net 
;tag=12<repeat count=50>982</repeat>424 

; unknownheaderparam<repeat count=20>name</repeat>= 

unknowheaderparam<repeat count=15>value</repeat> 
;unknownValueless«repeat count=10>paramname</repeat> 
</allOneLine> 

Call-ID: longreq.one<repeat count=20>really</repeat>longcallid 
CSeq: 3882340 INVITE 

<allOneLine> 

Unknown-<repeat count=20>Long</repeat>-Name: 
unknown-<repeat count=20>long</repeat>-value; 
unknown-<repeat count=20>long</repeat>-parameter-name = 
unknown-«repeat count=20>long</repeat>-parameter-value 
«/allOneLine» 

Via: SIP/2.0/TCP sip33.example.com 

v: SIP/2.0/TCP sip32.example.com 

V: SIP/2.0/TCP sip31.example.com 

Via: SIP/2.0/TCP sip30.example.com 

ViA: SIP/2.0/TCP sip29.example.com 

VIa: SIP/2.0/TCP sip28.example.com 

VIA: SIP/2.0/TCP sip27.example.com 

via: SIP/2.0/TCP sip26.example.com 

viA: SIP/2.0/TCP sip25.example.com 

via: SIP/2.0/TCP sip24.example.com 

vIA: SIP/2.0/TCP sip23.example.com 


V : SIP/2.0/TCP sip22.example.com 
v : SIP/2.0/TCP sip21.example.com 
V : SIP/2.0/TCP sip20.example.com 
v : SIP/2.0/TCP sipl9.example.com 
Via : SIP/2.0/TCP sipl8.example.com 
Via : SIP/2.0/TCP sipl7.example.com 


Via: SIP/2.0/TCP sipl6.example.com 
Via: SIP/2.0/TCP sipl5.example.com 
Via: SIP/2.0/TCP sipl4.example.com 
Via: SIP/2.0/TCP sipl3.example.com 
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Via: SIP/2.0/TCP sipl2.example.com 
Via: SIP/2.0/TCP sipll.example.com 
Via: SIP/2.0/TCP sipl0.example.com 
Via: SIP/2.0/TCP sip9.example.com 
Via: SIP/2.0/TCP sip8.example.com 
Via: SIP/2.0/TCP sip7.example.com 
Via: SIP/2.0/TCP sip6.example.com 
Via: SIP/2.0/TCP sip5.example.com 
Via: SIP/2.0/TCP sip4.example.com 
Via: SIP/2.0/TCP sip3.example.com 
Via: SIP/2.0/TCP sip2.example.com 
Via: SIP/2.0/TCP sipl.example.com 
<allOneLine> 
Via: SIP/2.0/TCP 

host.example.com; received=192.0.2.5; 
branch=very<repeat count=50>long</repeat>branchvalue 
</allOneLine> 
Max-Forwards: 70 

<allOneLine> 

Contact: <sip: 

<repeat count=5>amazinglylongcallername</repeat> 
@host5.example.net> 


</allOneLine> 

Content-Type: application/sdp 

1: 150 

v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.1 
se 

c=IN IP4 192.0.2.1 

t=0 0 


m=audio 49217 RTP/AVP 0 12 
m=video 3227 RTP/AVP 31 
a=rtpmap:31 LPC 


3.1.1.8. Extra Trailing Octets in a UDP Datagram 


This message contains a single SIP REGISTER request, which ostensibly 
arrived over UDP in a single datagram. The packet contains extra 


octets after the body (which in this case has zero length). The 
extra octets happen to look like a SIP INVITE request, but (per 
section 18.3 of [RFC3261]) they are just spurious noise that must be 
ignored. 


A SIP element receiving this datagram would handle the REGISTER 
request normally and ignore the extra bits that look like an INVITE 
request. If the element is a proxy choosing to forward the REGISTER, 
the INVITE octets would not appear in the forwarded request. 
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Message Details : dblreq 


REGISTER sip:example.com SIP/2.0 

To: sip:j.user@example.com 

From: sip: j.user@example.com; tag=432514345324 
Max-Forwards: 8 

I: dblreq.Oha0isndaksdj99sdfafnl31k233412 

Contact: sip:j.user(8ühost.example.com 

CSeq: 8 REGISTER 

Via: SIP/2.0/UDP 192.0.2.125;branch-z9hG4bKkdjuw23492 
Content-Length: 0 


INVITE sip: joe@example.com SIP/2.0 

t: sip: joe@example.com 

From: sip:caller@example.net;tag=141334 

Max-Forwards: 8 

Call-ID: dblreq. 0ha0isnda977644900765@192.0.2.15 
CSeq: 8 INVITE 

Via: SIP/2.0/UDP 192.0.2.15;branch-z9hG4bKkdjuw380234 
Content-Type: application/sdp 

Content-Length: 150 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.15 
s-- 

c=IN IP4 192.0.2.15 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m =video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 
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3.1.1.9. Semicolon-Separated Parameters in URI User Part 


May 2006 


This request has a semicolon-separated parameter contained in the 
"user" part of the Request-URI (whose value contains an escaped @ 
symbol). Receiving elements will accept this as a well-formed 
message. The Request-URI will parse so that the user part is 


"user; par=u@example.net". 


Message Details : semiuri 


OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0 

To: sip:j userGexample.com 

From: sip:caller@example.org; tag=33242 

Max-Forwards: 3 

Call-ID: semiuri.Oha0isndaksdj 

CSeq: 8 OPTIONS 

Accept: application/sdp, application/pkcs7-mime, 
multipart/mixed, multipart/signed, 
message/sip, message/sipfrag 

Via: SIP/2.0/UDP 192.0.2.1;branch-z9hG4bKkdjuw 

taco 


3.1.1.10. Varied and Unknown Transport Types 


This request contains Via header field values with all known 


transport types and exercises the transport extension mechanism. 
Parsers must accept this message as well formed. Elements receiving 
this message would process it exactly as if the 2nd and subsequent 


header field values specified UDP (or other transport). 
Message Details : transports 


OPTIONS sip:user@example.com SIP/2.0 

To: sip:user@example.com 

From: <sip:caller@example.com>; tag=323 

Max-Forwards: 70 

Call-ID: transports.kijh4akdnaqjkwendsasfdj 

Accept: application/sdp 

CSeq: 60 OPTIONS 

Via: SIP/2.0/UDP tl.example.com;branch-z9hG4bKkdjuw 
Via: SIP/2.0/SCTP t2.example.com;branch-z9hG4bKklasjdhf 
Via: SIP/2.0/TLS t3.example.com;branch-z9hGA4bK2980undd]j 


Via: SIP/2.0/UNKNOWN t4.example.com;branch-z9hG4bKasd0f3en 


Via: SIP/2.0/TCP t5.example.com;branch-z9hG4bK0a9idfnee 
Je c0 


Sparks, et al. Informational 


[Page 16] 


RFC 4475 SIP Torture Test Messages May 2006 


3.1.1.11. Multipart MIME Message 


This MESSAGE request contains two body parts. The second part is 
binary encoded and contains null (0x00) characters. Receivers must 
take care to frame the received message properly. 


Parsers must accept this message as well formed, even if the 
application above the parser does not support multipart/signed. 


Additional examples of multipart/mime messages, in particular S/MIME 
messages, are available in the security call flow examples document 
[SIP-SEC]. 


Message Details : mpart0Ol 


MESSAGE sip:kumiko@example.org SIP/2.0 

«allOneLine» 

Via: SIP/2.0/UDP 127.0.0.1:5070 
;branch-z9hG4bK-d87543-4dade06d0bdbl1ee-1--d87543-;rport 
«/allOneLine» 

Max-Forwards: 70 

Route: <sip:127.0.0.1:5080> 

«allOneLine» 

Identity: rSmwreLuyDRYBi/OTiPwEsY3rEVsk/G2WxhgIV1PF7hHuL 
IKOYWVKZhKv9Mj8UeXqkMVbnVq37CD-*813gvYjcBUaZngOmXc9WNZSDN 
GCzA-fWl19MEUHWIZolCeJebdY/XlgKeTa0O0l1vq0rt7005jiSfbqgMJmQF 
teeivUhkMWYUA- 

«/allOneLine» 

Contact: <sip:fluffy@127.0.0.1:5070> 

To: <sip:kumiko@example.org> 

From: <sip:fluffy@example.com>;tag=2fb0dcc9 

Call-ID: 3d9485ad0c49859bQZmxl1ZmzZ5LW1hYyOxNi5sb2NhbA.. 
CSeq: 1 MESSAGE 

Content-Transfer-Encoding: binary 

Content-Type: multipart/mixed;boundary-7a9cbec02ceef655 
Date: Sat, 15 Oct 2005 04:44:56 GMT 

User-Agent: SIPimp.org/0.2.5 (curses) 

Content-Length: 553 


--7a9cbec02ceef655 
Content-Type: text/plain 
Content-Transfer-Encoding: binary 


Hello 

--7a9cbec02ceef655 

Content-Type: application/octet-stream 
Content-Transfer-Encoding: binary 
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<hex> 

3082015206092A86 
4886F70D010702A08201433082013F02 
01013109300706052B0E03021A300B06 
092A864886F70D010701318201203082 
011C020101307C3070310B3009060355 
04061302555331133011060355040813 
0A43616C69666F726E69613111300F06 
03550407130853616E204A6F7365310E 
300C060355040A130573697069743129 
3027060355040B132053697069742054 
65737420436572746966696361746520 
417574686F7269747902080195007102 
330113300706052B0E03021A300D0609 
2A864886F70D01010105000481808EF4 
66F948F0522DD2E5978E9D95AAE9F2FE 
15A06659716292E8DA2AA8D8350A68CE 
FFAE3CBD2BFF1675DDD5648E593DD647 
28F26220F7E941749E330D9A15EDABDB 
93D10C42102E7B87289D29CCOC9AE2EFB 
C7COCFF9172F3B027E4FCO27E1546DE4 
B6AA3ABB3E66CCCB5DD6C64B8383149C 
B8E6FF182D944FE57B65BC99D005 
«/hex» 

--7a9cbec02ceef655-- 
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3.1.1172; 


This 200 response contains a reason phrase other than "OK". 


Unusual Reason Phrase 


The 


reason phrase is intended for human consumption and may contain any 


string produced by 


Reason-Phrase 


*(reserved / unreserved / escaped 


/ UTF8-NONASCII / UTF8-CONT / SP / HTAB) 


This particular response contains unreserved and non-ascii UTF-8 


characters. This response is well formed. 
message. 
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Message Details : unreason 
<allOneLine> 
SIP/2.0 200 = 2**3 * 5**2 <hex>DOBDDOBE20D181D182 
DOBE20D0B4D0B5D0B2D18FDOBDDOBED181D182D0BE20D0B4 
DOB5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 
BEDOB5</hex> 
</allOneLine> 
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1 324923 
Call-ID: unreason.1234ksdfak3j2erwedfsASdf 
CSeq: 35 INVITE 
From: sip:user@example.com; tag=11141343 
To: sip:user@example.edu; tag=2229 
Content-Length: 154 
Content-Type: application/sdp 
Contact: <sip:user@host198.example.com> 
v=0 
o=mhandley 29739 7272939 IN IP4 192.0.2.198 
s-- 
c=IN IP4 192.0.2.198 
t=0 0 
m=audio 49217 RTP/AVP 0 12 
m=video 3227 RTP/AVP 31 
a=rtpmap:31 LPC 
3.1.1.13. Empty Reason Phrase 
This well-formed response contains no reason phrase. A parser must 
accept this message. The space character after the reason code is 
required. If it were not present, this message could be rejected as 
invalid (a liberal receiver would accept it anyway). 
Message Details : noreason 
SIP/2.0 100<hex>20</hex> 
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 
Call-ID: noreason.asndj203insdf99223ndf 
CSeq: 35 INVITE 
From: <sip:user@example.com>;tag=39ansfi3 
To: «sip:user(üexample.edu»;tag-902jndnke3 
Content-Length: 0 
Contact: <sip:user@host105.example.com> 
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3.1.2. Invalid Messages 


This section contains several invalid messages reflecting errors seen 
at interoperability events and exploring important edge conditions 


that can be induced through malformed messages. This section does 
not attempt to be a comprehensive list of all types of invalid 
messages. 

3.1.2.1. Extraneous Header Field Separators 


The Via header field of this request contains additional semicolons 
and commas without parameters or values. The Contact header field 
contains additional semicolons without parameters. This message is 
syntactically invalid. 


An element receiving this request should respond with a 400 Bad 
Request error. 


Message Details : badinv01 


INVITE sip:user@example.com SIP/2.0 

To: sip:j.user@example.com 

From: sip:caller@example.net;tag=134161461246 
Max-Forwards: 7 

Call-ID: badinv01.0ha0isndaksdjasdf3234nas 
CSeq: 8 INVITE 

Vias SIP/2.0/UDP 192% 0.2.15 993% ¢ 

Contact: "Joe" <sip:joe@example.org>;;;; 
Content-Length: 152 

Content-Type: application/sdp 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.15 
s=- 

c=IN IP4 192.0.2.15 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 


3.1.2.2. Content Length Larger Than Message 


This is a request message with a Content Length that is larger than 
the actual length of the body. 


When sent over UDP (as this message ostensibly was), the receiving 


element should respond with a 400 Bad Request error. If this message 
arrived over a stream-based transport, such as TCP, there’s not much 
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the receiving party could do but wait for more data on the stream and 
close the connection if none is forthcoming within a reasonable 
period of time. 


Message Details : clerr 


INVITE sip:user@example.com SIP/2.0 

Max-Forwards: 80 

To: sip:j.user@example.com 

From: sip:caller@example.net; tag=9394293902 

Contact: <sip:caller@hungry.example.net> 

Call-ID: clerr.0ha0isndaksdjweiafasdk3 

CSeq: 8 INVITE 

Via: SIP/2.0/UDP host5.example.com;branch-z9hG4bK-39234-23523 
Content-Type: application/sdp 

Content-Length: 9999 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.155 
g== 

c=IN IP4 192.0.2.155 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 


3.1.2.3. Negative Content-Length 
This request has a negative value for Content-Length. 


An element receiving this message should respond with an error. This 
request appeared over UDP, so the remainder of the datagram can 
simply be discarded. If a request like this arrives over TCP, the 
framing error is not recoverable, and the connection should be 
closed. The same behavior is appropriate for messages that arrive 
without a numeric value in the Content-Length header field, such as 
the following: 


Content-Length: five 
Implementors should take extra precautions if the technique they 
choose for converting this ascii field into an integral form can 


return a negative value. In particular, the result must not be used 
as a counter or array index. 
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Message Details : ncl 


INVITE sip:user@example.com SIP/2.0 
Max-Forwards: 254 

To: sip:j.user@example.com 

From: sip:callerGexample.net;tag-32394234 
Call-ID: ncl.0ha0isndaksdj2193423r542w35 

CSeq: 0 INVITE 

Via: SIP/2.0/UDP 192.0.2.53;branch-z9hG4bKkdjuw 
Contact: <sip:caller@example53.example.net> 
Content-Type: application/sdp 

Content-Length: -999 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.53 
s=- 

c=IN IP4 192.0.2.53 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 


3.1.2.4. Request Scalar Fields with Overlarge Values 


This request contains several scalar header field values outside 
their legal range. 


o The CSeq sequence number is >2**32-1. 

o The Max-Forwards value is >255. 

o The Expires value is >2**32-1. 

o The Contact expires parameter value is >2**32—1. 


An element receiving this request should respond with a 400 Bad 
Request due to the CSeq error. If only the Max-Forwards field were 
in error, the element could choose to process the request as if the 
field were absent. If only the expiry values were in error, the 
element could treat them as if they contained the default values for 
expiration (3600 in this case). 


Other scalar request fields that may contain aberrant values include, 
but are not limited to, the Contact q value, the Timestamp value, and 
the Via ttl parameter. 
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Message Details : scalar02 


REGISTER sip:example.com SIP/2.0 

Via: SIP/2.0/TCP host129.example.com; branch=z9hG4bK342sdfoi3 

To: <sip:user@example.com> 

From: «sip:userGexample.com»;tag-239232jh3 

CSeq: 36893488147419103232 REGISTER 

Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32 

Max-Forwards: 300 

Expires: l<repeat count=100>0</repeat> 

Contact: <sip:user@host129.example.com> 
;expires-280297596632815 

Content-Length: 0 


3.1.2.5. Response Scalar Fields with Overlarge Values 


This response contains several scalar header field values outside 
their legal range. 


o The CSeq sequence number is >2**32-1. 


o The Retry-After field is unreasonably large (note that RFC 3261 
does not define a legal range for this field). 


o The Warning field has a warning-value with more than 3 digits. 
An element receiving this response will simply discard it. 
Message Details : scalarlg 


SIP/2.0 503 Service Unavailable 

<allOneLine> 

Via: SIP/2.0/TCP host129.example.com 
;branch=z9hG4bKzzxdiwo34sw 
;received-192.0.2.129 

«/allOneLine» 

To: <sip:user@example.com> 

From: «sip:otherGexample.net»;tag-2easdjfejw 
CSeq: 9292394834772304023312 OPTIONS 
Call-ID: scalarlg.noase00f0234hn2qofoaf0232aewf2394r 
Retry-After: 949302838503028349304023988 
Warning: 1812 overture "In Progress" 
Content-Length: 0 
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3.1.2.6. Unterminated Quoted String in Display Name 


This is a request with an unterminated quote in the display name 
the To field. An element receiving this request should return a 
Bad Request error. 


An element could attempt to infer a terminating quote and accept 
message. Such an element needs to take care that it makes a 
reasonable inference when it encounters 


2006 


of 
400 


the 


To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net> 


Message Details : quotbal 


INVITE sip:user@example.com SIP/2.0 

To: "Mr. J. User <sip:j.user@example.com> 

From: sip:callerGexample.net;tag-93334 

Max-Forwards: 10 

Call-ID: quotbal.aksdj 

Contact: <sip:caller@host59.example.net> 

CSeq: 8 INVITE 

Via: SIP/2.0/UDP 192.0.2.59:5050; branch-z9hG4bKkdjuw39234 
Content-Type: application/sdp 

Content-Length: 152 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.15 
s-- 

c=IN IP4 192.0.2.15 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m-video 3227 RTP/AVP 31 

a-rtpmap:31 LPC 
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3.1.2.7. <> Enclosing Request-URI 


This INVITE request is invalid because the Request-URI has been 
enclosed within in "<>". 


It is reasonable always to reject a request with this error with a 
400 Bad Request. Elements attempting to be liberal with what they 


accept may choose to ignore the brackets. If the element forwards 
the request, it must not include the brackets in the messages it 
sends. 

Message Details : ltgtruri 


INVITE <sip:user@example.com> SIP/2.0 
To: sip:user@example.com 

From: sip:callerGexample.net;tag-39291 
Max-Forwards: 23 

Call-ID: ltgtruri.1@192.0.2.5 

CSeq: 1 INVITE 

Via: SIP/2.0/UDP 192.0.2.5 

Contact: <sip:caller@host5.example.net> 
Content-Type: application/sdp 
Content-Length: 159 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.5 
s=- 

c=IN IP4 192.0.2.5 

t=3149328700 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 


Sparks, et al. Informational [Page 25] 


RFC 4475 SIP Torture Test Messages May 2006 


3.1.2.8. Malformed SIP Request-URI (embedded LWS) 
This INVITE has illegal LWS within the Request-URI. 


An element receiving this request should respond with a 400 Bad 
Request. 


An element could attempt to ignore the embedded LWS for those schemes 
(like SIP) where doing so would not introduce ambiguity. 


Message Details : lwsruri 


INVITE sip:user@example.com; lr SIP/2.0 

To: sip:user(üexample.com;tag-3xfe-9921883-z9f 

From: sip:caller8example.net;tag-231413434 
Max-Forwards: 5 

Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 
CSeq: 2130706432 INVITE 

Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395 
Contact: <sip:caller@host1l.example.net> 

Content-Type: application/sdp 

Content-Length: 159 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.1 
s=- 

c=IN IP4 192.0.2.1 

t=3149328700 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 
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3.1.2.9. Multiple SP Separating Request-Line Elements 


This INVITE has illegal multiple SP characters between elements of 
the start line. 


It is acceptable to reject this request as malformed. An element 
that is liberal in what it accepts may ignore these extra SP 
characters when processing the request. If the element forwards the 
request, it must not include these extra SP characters in the 
messages it sends. 


Message Details : lwsstart 


INVITE sip:user@example.com SIP/2.0 

Max-Forwards: 8 

To: sip:user@example.com 

From: sip:caller@example.net;tag=8814 

Call-ID: lwsstart.dfknq23401243099adsdfnawe3@example.com 
CSeq: 1893884 INVITE 

Via: SIP/2.0/UDP hostl.example.com;branch=z9hG4bKkdjuw3923 
Contact: <sip:caller@hostl.example.net> 

Content-Type: application/sdp 

Content-Length: 150 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.1 
s=- 

c=IN IP4 192.0.2.1 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 
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3.1.2.10. SP Characters at End of Request-Line 


This OPTIONS request contains SP characters between the SIP-Version 
field and the CRLF terminating the Request-Line. 


It is acceptable to reject this request as malformed. An element 
that is liberal in what it accepts may ignore these extra SP 
characters when processing the request. If the element forwards the 
request, it must not include these extra SP characters in the 
messages it sends. 


Message Details : trws 


OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex> 
Via: SIP/2.0/TCP hostl.example.com; branch=z9hG4bK2 99342093 
To: <sip:remote-target@example.com> 

From: <sip:local-resource(example.com>;tag=329429089 
Call-ID: trws.oicu34958239neffasdhr2345r 

Accept: application/sdp 

CSeq: 238923 OPTIONS 

Max-Forwards: 70 

Content-Length: 0 
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3.1.2.11. Escaped Headers in SIP Request-URI 


This INVITE is malformed, as the SIP Request-URI contains escaped 
headers. 


It is acceptable for an element to reject this request with a 400 Bad 
Request. An element could choose to be liberal in what it accepts 
and ignore the escaped headers. If the element is a proxy, the 
escaped headers must not appear in the Request-URI of the forwarded 
request (and most certainly must not be translated into the actual 
header of the forwarded request). 


Message Details : escruri 


INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0 
To: sip:user@example.com 

From: sip:caller@example.net;tag=341518 

Max-Forwards: 7 

Contact: <sip:caller@host39923.example.net> 

Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 

CSeq: 149209342 INVITE 

Via: SIP/2.0/UDP host-of-the-hour.example.com;branch-z9hG4bKkdjuw 
Content-Type: application/sdp 

Content-Length: 150 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.1 
s-- 

C-IN IPA 192.0.2.1 

t-0 0 

m=audio 49217 RTP/AVP 0 12 

m-video 3227 RTP/AVP 31 

a-rtpmap:31 LPC 
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3.1.2.12. Invalid Time Zone in Date Header Field 


This INVITE is invalid, as it contains a non-GMT time zone in the SIP 
Date header field. 


It is acceptable to reject this request as malformed (though an 
element shouldn’t do that unless the contents of the Date header 
field were actually important to its processing). An element wishing 
to be liberal in what it accepts could ignore this value altogether 
if it wasn’t going to use the Date header field anyway. Otherwise, 
it could attempt to interpret this date and adjust it to GMT. 


RFC 3261 explicitly defines the only acceptable time zone designation 
as "GMT". "UT", while synonymous with GMT per [RFC2822], is not 
valid. "UTC" and "UCT" are also invalid. 


Message Details : baddate 


INVITE sip:user@example.com SIP/2.0 

To: sip:user@example.com 

From: sip:caller@example.net;tag=2234923 
Max-Forwards: 70 

Call-ID: baddate.239423mnsadf3j231j42--sedfnm234 
CSeq: 1392934 INVITE 

Via: SIP/2.0/UDP host.example.com;branch-z9hG4bKkdjuw 
Date: Fri, 01 Jan 2010 16:00:00 EST 

Contact: <sip:caller@host5.example.net> 
Content-Type: application/sdp 

Content-Length: 150 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.5 
g== 

C-IN IP4 192.0.2.5 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m-video 3227 RTP/AVP 31 

a-rtpmap:31 LPC 
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3.1.2.13. Failure to Enclose name-addr URI in <> 


This REGISTER request is malformed. The SIP URI contained in the 
Contact Header field has an escaped header, so the field must be in 
name-addr form (which implies that the URI must be enclosed in <>). 


It is reasonable for an element receiving this request to respond 
with a 400 Bad Request. An element choosing to be liberal in what it 
accepts could infer the angle brackets since there is no ambiguity in 
this example. In general, that won’t be possible. 


Message Details : regbadct 


REGISTER sip:example.com SIP/2.0 

To: sip:user@example.com 

From: sip:user@example.com; tag=998332 

Max-Forwards: 70 

Call-ID: regbadct.k345asrl3fdbvG10.0.0.1 

CSeq: 1 REGISTER 

Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 
1: 0 


3.1.2.14. Spaces within addr-spec 


This request is malformed, since the addr-spec in the To header field 
contains spaces.  Parsers receiving this request must not break. It 

is reasonable to reject this request with a 400 Bad Request response. 
Elements attempting to be liberal may ignore the spaces. 


Message Details : badaspec 


OPTIONS sip:user@example.org SIP/2.0 

Via: SIP/2.0/UDP host4.example.com:5060;branch-z9hG4bKkdju43234 
Max-Forwards: 70 

From: "Bell, Alexander" <sip:a.g.bell@example.com>; tag=433423 
To: "Watson, Thomas" « sip:t.watson@example.org > 

Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3 

Accept: application/sdp 

CSeq: 3923239 OPTIONS 

1: 0 
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3.1.2.15. Non-token Characters in Display Name 


This OPTIONS request is malformed, since the display names in the To 
and From header fields contain non-token characters but are unquoted. 


It is reasonable always to reject this kind of error with a 400 Bad 
Request response. 


An element may attempt to be liberal in what it receives and infer 
the missing quotes. If this element were a proxy, it must not 
propagate the error into the request it forwards. As a consequence, 
if the fields are covered by a signature, there's not much point in 
trying to be liberal - the message should simply be rejected. 


Message Details : baddn 


OPTIONS sip:t.watson@example.org SIP/2.0 


Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw 
Max-Forwards: 70 

From: Bell, Alexander <sip:a.g.bell@example.com>;tag=43 
TOS Watson, Thomas <sip:t.watson@example.org> 


Call-ID: baddn.314158c.example.com 
Accept: application/sdp 
CSeq: 3923239 OPTIONS 
1: 0 
3.1.2.16. Unknown Protocol Version 


To an element implementing [RFC3261], this request is malformed due 
to its high version number. 


The element should respond to the request with a 505 Version Not 
Supported error. 


Message Details : badvers 


OPTIONS sip:t.watson@example.org SIP/7.0 


Via: SIP/7.0/UDP c.example.com;branch-z9hG4bKkdjuw 
Max-Forwards: 70 

From: A. Bell «sip:a.g.bellüexample.com»;tag-qweoigqpe 
Tos T. Watson <sip:t.watson@example.org> 

Call-ID: badvers.31417@c.example.com 

CSeq: 1 OPTIONS 

1: 0 
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3.1.2.17. Start Line and CSeq Method Mismatch 


This request has mismatching values for the method in the start line 
and the CSeq header field. Any element receiving this request will 
respond with a 400 Bad Request. 


Message Details : mismatch01 


OPTIONS sip:user@example.com SIP/2.0 

To: sip:j.user@example.com 

From: sip:caller@example.net;tag=34525 

Max-Forwards: 6 

Call-ID: mismatch01.dj0234sxdf13 

CSeq: 8 INVITE 

Via: SIP/2.0/UDP host.example.com;branch-z9hG4bKkdjuw 
lt 0 


3.1.2.18. Unknown Method with CSeq Method Mismatch 


This message has an unknown method in the start line, and a CSeq 
method tag that does not match. 


Any element receiving this response should respond with a 501 Not 
Implemented. A 400 Bad Request is also acceptable, but choosing a 
501 (particularly at proxies) has better future-proof 
characteristics. 


Message Details : mismatch02 


NEWMETHOD sip:user@example.com SIP/2.0 

To: sip:j.user@example.com 

From: sip:callerGexample.net;tag-34525 

Max-Forwards: 6 

Call-ID: mismatch02.dj0234sxdf13 

CSeq: 8 INVITE 

Contact: <sip:caller@host.example.net> 

Via: SIP/2.0/UDP host.example.net;branch-z9hG4bKkdjuw 
Content-Type: application/sdp 

1: 138 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.1 
c=IN IP4 192.0.2.1 

m-audio 49217 RTP/AVP 0 12 

m-video 3227 RTP/AVP 31 

a-rtpmap:31 LPC 
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3.1.2.19. Overlarge Response Code 


This response has a response code larger than 699. An element 
receiving this response should simply drop it. 


Message Details : bigcode 


SIP/2.0 4294967301 better not break the receiver 

Via: SIP/2.0/UDP 192.0.2.105;branch-z9hG4bK2398ndaoe 
Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i 
CSeq: 353494 INVITE 
From: <sip:user@example.com>;tag=39ansfi3 
To: <sip:user@example.edu>; tag=902 jndnke3 
Content-Length: 0 

Contact: <sip:user@host105.example.com> 


3.2. Transaction Layer Semantics 


This section contains tests that exercise an implementation’s parser 
and transaction-layer logic. 


3.2.1. Missing Transaction Identifier 


This request indicates support for RFC 3261-style transaction 
identifiers by providing the z9hG4bK prefix to the branch parameter, 
but it provides no identifier. A parser must not break when 
receiving this message. An element receiving this request could 
reject the request with a 400 Response (preferably statelessly, as 
other requests from the source are likely also to have a malformed 
branch parameter), or it could fall back to the RFC 2543-style 
transaction identifier. 


Message Details : badbranch 


OPTIONS sip:user@example.com SIP/2.0 

To: sip:user@example.com 

From: sip:callerGexample.org;tag-33242 
Max-Forwards: 3 

Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK 
Accept: application/sdp 

Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n 
CSeq: 8 OPTIONS 

1: 0 
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3.3. Application-Layer Semantics 


This section contains tests that exercise an implementation’s parser 
and application-layer logic. 


3.3.1. Missing Required Header Fields 
This request contains no Call-ID, From, or To header fields. 


An element receiving this message must not break because of the 


missing information. Ideally, it will respond with a 400 Bad Request 
error. 
Message Details : insuf 


INVITE sip:user@example.com SIP/2.0 

CSeq: 193942 INVITE 

Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf 
Content-Type: application/sdp 

bs 152 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.95 
= 

c=IN IP4 192.0.2.95 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m-video 3227 RTP/AVP 31 

a-rtpmap:31 LPC 
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.2.  Request-URI with Unknown Scheme 


This OPTIONS contains an unknown URI scheme in the Request-URI. A 
parser must accept this as a well-formed SIP request. 


An element receiving this request will reject it with a 416 
Unsupported URI Scheme response. 


Some early implementations attempt to look at the contents of the To 
header field to determine how to route this kind of request. That is 
an error. Despite the fact that the To header field and the Request 
URI frequently look alike in simplistic first-hop messages, the To 
header field contains no routing information. 


Message Details : unkscm 


OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0 
To: sip:user@example.com 

From: sip:caller@example.net;tag=384 

Max-Forwards: 3 

Call-ID: unkscm.nasdfasser0q239nwsdfasdk134 

CSeq: 3923423 OPTIONS 

Via: SIP/2.0/TCP host9.example.com;branch-z9hG4bKkdjuw39234 
Content-Length: 0 


3. Request-URI with Known but Atypical Scheme 


This OPTIONS contains an Request-URI with an IANA-registered scheme 
that does not commonly appear in Request-URIs of SIP requests. A 
parser must accept this as a well-formed SIP request. 


If an element will never accept this scheme as meaningful ina 
Request-URI, it is appropriate to treat it as unknown and return a 
416 Unsupported URI Scheme response. If the element might accept 
some URIs with this scheme, then a 404 Not Found is appropriate for 
those URIs it doesn’t accept. 


Message Details : novelsc 


OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0 

To: sip:user@example.com 

From: sip:caller@example.net;tag=384 

Max-Forwards: 3 

Call-ID: novelsc.asdfasser0q239nwsdfasdk134 

CSeq: 3923423 OPTIONS 

Via: SIP/2.0/TCP host9.example.com;branch-z9hG4bKkdjuw39234 
Content-Length: 0 


Sparks, et al. Informational [Page 36] 


RFC 4475 SIP Torture Test Messages May 2006 


3.3.4. Unknown URI Schemes in Header Fields 


This message contains registered schemes in the To, From, and Contact 
header fields of a request. The message is syntactically valid. 
Parsers must not fail when receiving this message. 


Proxies should treat this message as they would any other request for 
this URI. A registrar would reject this request with a 400 Bad 
Request response, since the To: header field is required to contain a 
SIP or SIPS URI as an AOR. 


Message Details : unksm2 


REGISTER sip:example.com SIP/2.0 

To: isbn:2983792873 

From: «http://www.example.com»;tag-3234233 

Call-ID: unksm2.daksdjGhyphenated-host.example.com 
CSeq: 234902 REGISTER 

Max-Forwards: 70 

Via: SIP/2.0/UDP 192.0.2.21:5060; branch-z9hG4bKkdjuw 
Contact: «name:John Smith» 

1: 0 


3.3.5. Proxy-Require and Require 


This request tests proper implementation of SIP's Proxy-Require and 
Require extension mechanisms. 


Any element receiving this request will respond with a 420 Bad 
Extension response, containing an Unsupported header field listing 
these features from either the Require or Proxy-Require header field, 
depending on the role in which the element is responding. 


Message Details : bext01 


OPTIONS sip:user@example.com SIP/2.0 

To: sip:j userGexample.com 

From: sip:caller@example.net;tag=242etr 

Max-Forwards: 6 

Call-ID: bext01.0ha0isndaksdj 

Require: nothingSupportsThis, nothingSupportsThisEither 
Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis 
CSeq: 8 OPTIONS 

Via: SIP/2.0/TLS fold-and-staple.example.com;branch-z9hG4bKkdjuw 
Content-Length: 0 
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3:3. 


34-35 


Spa 


6. Unknown Content-Type 


This INVITE request contains a body of unknown type. It is 
syntactically valid. A parser must not fail when receiving it. 


A proxy receiving this request would process it just as it would any 
other INVITE. An endpoint receiving this request would reject it 
with a 415 Unsupported Media Type error. 


Message Details : invut 


INVITE sip:user@example.com SIP/2.0 

Contact: <sip:caller@host5.example.net> 

To: sip:j.user@example.com 

From: sip:caller@example.net;tag=8392034 

Max-Forwards: 70 

Call-ID: invut.Oha0isndaksdjadsfij34n23d 

CSeq: 235448 INVITE 

Via: SIP/2.0/UDP somehost.example.com;branch-z9hG4bKkdjuw 
Content-Type: application/unknownformat 

Content-Length: 40 


«audio» 
<pcmu port="443"/> 
«/audio» 
7. Unknown Authorization Scheme 


This REGISTER request contains an Authorization header field with an 
unknown scheme. The request is well formed. A parser must not fail 
when receiving it. 


A proxy will treat this request as it would any other REGISTER. If 
it forwards the request, it will include this Authorization header 
field unmodified in the forwarded messages. 


A registrar that does not care about challenge-response 
authentication will simply ignore the Authorization header field, 
processing this registration as if the field were not present. A 
registrar that does care about challenge-response authentication will 
reject this request with a 401, issuing a new challenge with a scheme 
it understands. 


Endpoints choosing not to act as registrars will simply reject the 
request. A 405 Method Not Allowed is appropriate. 
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Message Details : regautO0l 


REGISTER sip:example.com SIP/2.0 

To: sip:j.user@example.com 

From: sip: j.user@example.com; tag=87321hj23128 
Max-Forwards: 8 

Call-ID: regaut01.0ha0isndaksdj 

CSeq: 9338 REGISTER 

Via: SIP/2.0/TCP 192.0.2.253;branch-z9hG4bKkdjuw 
Authorization: NoOneKnowsThisScheme opaque-data-here 
Content-Length:0 


3.3.8. Multiple Values in Single Value Required Fields 


The message contains a request with multiple Call-ID, To, From, Max- 
Forwards, and CSeq values. An element receiving this request must 
not break. 


An element receiving this request would respond with a 400 Bad 
Request error. 


Message Details : multiO0l 


INVITE sip:user@company.com SIP/2.0 
Contact: <sip:caller@host25.example.net> 
Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw 
Max-Forwards: 70 

CSeq: 5 INVITE 

Call-ID: multi01l.98asdh@192.0.2.1 

CSeq: 59 INVITE 

Call-ID: multi01l.98asdh@192.0.2.2 

From: sip:caller@example.com; tag=3413415 
To: sip:user@example.com 

To: sip:other@example.net 

From: sip:caller@example.net; tag=2923420123 
Content-Type: application/sdp 

1: 154 

Contact: <sip:caller@host36.example.net> 
Max-Forwards: 5 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.25 
s=- 

c=IN IP4 192.0.2.25 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 
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3.3.9. Multiple Content-Length Values 


Multiple conflicting Content-Length header field values appear in 
this request. 


From a framing perspective, this situation is equivalent to an 
invalid Content-Length value (or no value at all). 


An element receiving this message should respond with an error. This 
request appeared over UDP, so the remainder of the datagram can 


simply be discarded. If a request like this arrives over TCP, the 
framing error is not recoverable, and the connection should be 
closed. 


Message Details : mcl101 


OPTIONS sip:user@example.com SIP/2.0 

Via: SIP/2.0/UDP host5.example.net;branch-z9hG4bK293423 
To: sip:user@example.com 

From: sip:otherGexample.net;tag-3923942 

Call-ID: mcl01.fhn2323orihawfdoa3o4r5203irsdf 

CSeq: 15932 OPTIONS 

Content-Length: 13 

Max-Forwards: 60 

Content-Length: 5 

Content-Type: text/plain 


There's no way to know how many octets are supposed to be here. 
3.3.10. 200 OK Response with Broadcast Via Header Field Value 
This message is a response with a 2nd Via header field value's sent- 
by containing 255.255.255.255. The message is well formed; parsers 


must not fail when receiving it. 


Per [RFC3261], an endpoint receiving this message should simply 
discard it. 


If a proxy followed normal response processing rules blindly, it 


would forward this response to the broadcast address. To protect 
against this as an avenue of attack, proxies should drop such 
responses. 
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Message Details : bcast 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP 192.0.2.198;branch-z9hG4bK1324923 

Via: SIP/2.0/UDP 255.255.255.255;/branch=z9hG4bKlsaber23 
Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf 

CSeq: 35 INVITE 

From: sip:userGexample.com;tag-11141343 

To: sip:user(üexample.edu;tag-2229 

Content-Length: 154 

Content-Type: application/sdp 

Contact: <sip:user@host28.example.com> 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.198 
s=- 

c=IN IP4 192.0.2.198 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 


3.3.11. Max-Forwards of Zero 


This is a legal SIP request with the Max-Forwards header field value 
set to zero. 


A proxy should not forward the request and should respond 483 (Too 
Many Hops). An endpoint should process the request as if the Max- 
Forwards field value were still positive. 


Message Details : zeromf 


OPTIONS sip:user@example.com SIP/2.0 

To: sip:user@example.com 

From: sip:caller@example.net;tag=3ghsd41 

Call-ID: zeromf.jfasdlfnm202143r5u0asdfas 

CSeq: 39234321 OPTIONS 

Via: SIP/2.0/UDP hostl.example.com;branch-z9hG4bKkdjuw2349i 
Max-Forwards: 0 

Content-Length: 0 
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3.3.12. REGISTER with a Contact Header Parameter 


This register request contains a contact where the 'unknownparam' 
parameter must be interpreted as a contact-param and not a url-param. 


This REGISTER should succeed. The response must not include 
"unknownparam" as a url-parameter for this binding. Likewise, 
"unknownparam" must not appear as a url-parameter in any binding 
during subsequent fetches. 


Behavior is the same, of course, for any known contact-param 
parameter names. 


Message Details : cparam01 


REGISTER sip:example.com SIP/2.0 

Via: SIP/2.0/UDP saturn.example.com:5060;branch-z9hG4bKkdjuw 
Max-Forwards: 70 

From: sip:watsonGexample.com;tag-DkfVgjkrtMwaerKKpe 

To: sip:watson@example.com 

Call-ID: cparam01.70710@saturn.example.com 

CSeq: 2 REGISTER 

Contact: sip:+19725552222@gwl.example.net;unknownparam 

V: 0 


3.3.13. REGISTER with a url-parameter 


This register request contains a contact where the URI has an unknown 
parameter. 


The register should succeed, and a subsequent retrieval of the 
registration must include "unknownparam" as a url-parameter. 


Behavior is the same, of course, for any known url-parameter names. 
Message Details : cparam02 


REGISTER sip:example.com SIP/2.0 

Via: SIP/2.0/UDP saturn.example.com:5060;branch-z9hG4bKkdjuw 
Max-Forwards: 70 

From: sip:watsonGexample.com;tag-838293 

To: sip:watson@example.com 

Call-ID: cparam02.70710@saturn.example.com 

CSeq: 3 REGISTER 

Contact: <sip:+19725552222@gwl1l.example.net; unknownparam> 
psu 
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3.3.14. REGISTER with a URL Escaped Header 


This register request contains a contact where the URI has an escaped 
header. 


The register should succeed, and a subsequent retrieval of the 
registration must include the escaped Route header in the contact URI 
for this binding. 


Message Details : regescrt 


REGISTER sip:example.com SIP/2.0 

To: sip:user@example.com 

From: sip:user@example.com;tag=8 

Max-Forwards: 70 

Call-ID: regescrt.k345asrl3fdbve192.0.2.1 

CSeq: 14398234 REGISTER 

Via: SIP/2.0/UDP host5.example.com; branch=z9hG4bKkdjuw 

M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E> 
L:0 
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3.3.15. Unacceptable Accept Offering 


This request indicates that the response must contain a body in an 
unknown type. In particular, since the Accept header field does not 
contain application/sdp, the response may not contain an SDP body. 
The recipient of this request could respond with a 406 Not 
Acceptable, with a Warning/399 indicating that a response cannot be 
formulated in the formats offered in the Accept header field. It is 
also appropriate to respond with a 400 Bad Request, since all SIP 
User-Agents (UAs) supporting INVITE are required to support 
application/sdp. 


Message Details : sdp01 


INVITE sip:user@example.com SIP/2.0 

To: sip:j_user@example.com 

Contact: <sip:caller@host15.example.net> 
From: sip:caller@example.net;tag=234 
Max-Forwards: 5 

Call-ID: sdp01.ndaksdj9342dasdd 

Accept: text/nobodyKnowsThis 

CSeq: 8 INVITE 

Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw 
Content-Length: 150 

Content-Type: application/sdp 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.5 
== 

c=IN IP4 192.0.2.5 

t=0 0 

m=audio 49217 RTP/AVP 0 12 

m=video 3227 RTP/AVP 31 

a=rtpmap:31 LPC 


3.4. Backward Compatibility 

3.4.1. INVITE with RFC 2543 Syntax 
This is a legal message per RFC 2543 (and several bis versions) that 
should be accepted by RFC 3261 elements that want to maintain 
backwards compatibility. 


o There is no branch parameter at all on the Via header field value. 


o There is no From tag. 
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o There is no explicit Content-Length. (The body is assumed to be 
all octets in the datagram after the null-line.) 


o There is no Max-Forwards header field. 
Message Details : inv2543 


INVITE sip:UserB@example.com SIP/2.0 

Via: SIP/2.0/UDP iftgw.example.com 

From: <sip:+13035551111@ift.client.example.net;user=phone> 
Record-Route: <sip:UserB@example.com;maddr=ssl.example.com> 
To: sip:+16505552222@ssl.example.net;user=phone 

Call-ID: inv2543.1717@ift.client.example.com 

CSeq: 56 INVITE 

Content-Type: application/sdp 


v=0 

o=mhandley 29739 7272939 IN IP4 192.0.2.5 
s=- 

c=IN IP4 192.0.2.5 

t=0 0 

m=audio 49217 RTP/AVP 0 


4. Security Considerations 


This document presents NON-NORMATIVE examples of SIP session 
establishment. The security considerations in [RFC3261] apply. 


Parsers must carefully consider edge conditions and malicious input 
as part of their design. Attacks on many Internet systems use 
crafted input to cause implementations to behave in undesirable ways. 
Many of the messages in this document are designed to stress a parser 
implementation at points traditionally used for such attacks. 
However, this document does not attempt to be comprehensive. It 
should be considered a seed to stimulate thinking and planning, not 
simply a set of tests to be passed. 
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Appendix A.  Bit-Exact Archive of Each Test Message 


The following text block is an encoded, gzip-compressed TAR archive 
of files that represent each of the example messages discussed in 
Section 3. 


To recover the compressed archive file intact, the text of this 
document may be passed as input to the following Perl script (the 
output should be redirected to a file or piped to "tar -xzvf -"). 


#!/usr/bin/perl 
use strict; 
my Sbdata = ""; 
use MIME: :Base64; 
while(<>) { 
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 
if ( m/*\s*[*\s]+\s*S/) I 
Sbdata = $bdata . $; 


) 
) 
print decode base64(S$bdata); 


Figure 58 
Alternatively, the base-64 encoded block can be edited by hand to 


remove document structure lines and fed as input to any base-64 
decoding utility. 
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Encoded Reference Messages 


-- BEGIN MESSAGE ARCHIVE -- 

HASIAEDwCEMCA-*xdW2zc2Hm2nexNG6UNGLRFOQfaiKJdyxwdnkMOhyOPVrIt 
271t22tdvHYTeM8MDzWCcAZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF 
9rJPLYoWrTdAg6JFHwpOi-*5DOSIOoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f/ 
//3Xc04Rq9ipklJGxe6xITVAWl1YUvXc5K/W8syYheEygPOlIECWJOgkSkMAx 
DhwbQWsA4ALrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2 
cKlukIxlb3Prq7fmYQZMT23pON/+Nr958RZXthxXZzLRpSlYtL4ESWCja2CyV 
Cw-U8mWxeK2qVhoigkicnlrDe/wly25iW3XynEwPecmmO3GnzxPDOMstG/RQ 
pkrs09w5diU4s50pO0ilLgTMsLrh4uyAiJEIOPbVhOZ3vYNexzLPcRtmqYYfu 
692Gm216v/fcyuLOlAVsGPzqxTxXbPO802gAXp4JTdUBGChKA6IyKptmEwCl 
pFZNOs-OXCqRupvncLlu6CXs6pY576hlerxlspPnkALpLSpcqyOnp4w8R29v 
eurpeP60L/yHNkQAGCT/IsiG5R8KMJX/sco/lbiu/DNpi6NoizHbVqLilYsf 
nSAiBEUYBgAUAymCOQj91YEYIochBEhiQ6BYXOl1ilTM2CSBchqOwC7AAKKxqq 
ILMt sbmnVVaHJP 9U8Mkwlf8g+RcAFI+xf6IIBJRFVP7FbDbV/yNpqze2VjdW 
j178TeJ64g*pflWYwo5aAEHp9XiOqlGq22smlWEqsBAZFRHyvENUzaxb5VoQv 
vwIVuQoSOf /S+xgnQdskxixpTk9dpKfMc5ds/SwHBO4qNjlIWZETSnkA6B+3 
sr5Bz2iZLi5R7DkXuEd2fCkTuNNFn5SCYLr+xXydxSNXafJ2Y226Z30Pk4c5u 
gb5ZhVazZGj8G2eegI INTQOYyvUGF3iC3ekvsAKMOPeUU+0mpUiG6wS0AhmS1 
Am60usXRLhdk7vbGrfnlrVscvSnItu3qKrE4BGF3ExKmp3DBdus1XM8jgbt+ 
68KzjIbPJv6bQOX/BP6fgEL2n4gkKcX/Udt/sY5Trw/IWhBqS018wGYY/Db3W 
dOJpC7mBg71AXyl5rdcL9HeNu5WQCOjZnvKbIC313MNAf4-*2Pi7fÜyr/urkL 
hHHGf2QEwvafDFAq/xNn/1Uyj2bEBCkgUstSiF6CYjZiBvSLpcyloY6A7poqr 
jlrBDrUFWYwGO13/ra/11/EhpYWFswtnzwYMuNNXLdKKLIUSOOMLC7TEmWhw 
oF13SAtO6GvCCeOyAWiv7xLbGaf/BOÜOxqP81T/5RNpX/idH/ckT/y3H6P6nq 
79H8yx1P+0Q/S+DtNYuk7dRLQO+xuZlupPrPI9TmdKXw4r/Y5uF56x4FCxhKmz 
PFb7n4p+JP6Dsqn8j6S1itCcHAeBuXjtIpSq5kHwLCPqhncg+UJIygVd4PwcX 
icl27Mqmx4UA5cScCCAQqMKny1/DVVSBxG4SVXOW11Wtk30ROiZA1/wiImyat 
8SFQaUdtdyFCRtRGKOoFl1TgLOEWU2OkGiLyDs/AQzAXxZfHwloKS62sqsElp 
vCdtR4P/ZM8drveXIP4jS2H7T4RCiv+T1/+r3H+cFIATiWuHDcFSEP5 9Juxx 
/KanbpOdhm5TODUtt 6yb2+uNet 2yxXWe jrDtn435c0d0yoSe6Z2Vt7+3xgd/aD 
TpwWbXt /+6K1bO5Ht 8XkCXs03Mb1dU6zDJWnQM5T7vEUySArOKxbJsWyLOrb 
JUsda/4PSIIY8f£/S+M907T8RKQKSIREQGDS 6LrGZgHFFmt+AgR6WKsOmJ6LtM 
uvpbiCBs6UGk5KgAWyQo6y2Gw45qaahRgODRj6aG6BUO6KeyhhlEyl7gBzuK 
3rX5kKillbvvXBxs-*Q4jUrDpaHrL8jsXZ/r5hAqAFVM1q6zWJOZK*xh49GY]j 
Ft7TqP9LFLHtMed/5CwM*3/UaE/1f2Liv72aO/ekEWGF5fnpPwv287A3zG17 
P5xhbyOIz7I9xkKT6JiihVpFCYLEven7qMbmWX5H5CGSIDpOYl-t*h7THiwgcE 
hocbGS5Rpsal8eZ/JCBE9b+cyv802u2Vy6vrGyu3PXmNFf6I/DjYbdjmYyV+ 
u5SFfdrpQvLYds7lYlba2K1XbxXWtiYl+71976xu8SBIY2LiPuECBS9Drb4AC5 
9mOHAIgdfk5QZEhZENK2tNOUghCOODCrptUOvZN8YqLDrT6D45R/MStH5B4m 
+v9Z1f8cylEleTiZhwNlHsXJ/L1DCf3iJzAnpBYNm+yMNf4nICkbtv+ltP5r 
UuQ/makf3doql1IKSUEEVBCODgHLTU6t5rsV/Pda80jDfXzMNZFQhQqIAQ2q6 
dbJwnW/X9u-Kev90BZTiEMsrV-4TrqgMX3PWWgkUkPf3Vvsbe7UkKZajTi-*K6 
qON24c5SZJnKleJJOl1KwlOQwhTIxnYBywK-*3Hn5R85O0OXxHCJPZ800xVtxCkN 
0/0zOP+P5DD+wzT+M/L4D305M2iZQeuMCALYFUSqqF6YKkSWHzMgwDu08+2p1 
BLLE2iX0jXZhiTjJB47VisCgXwT1l5ekrPcz5/spEhQPFCwtVK1YTIMukXwKPA 
SBDIBoaKScM+DHT jJEZUHJPmnp7hOnGomeyFuKMgC/2Z12x01I5kxVqpLBL34wG 
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vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/a0z/GVGmt VKMKPk+ 
gE22dcelsZ3p6w2cnrlHyVvF1iDZxrIZd6jF2FzvD+wdSevCvOQQQOrWNUqPUVh 
PmsyODd3mhYS7R21dCRWbJYbLJkGRKZtVE2H1YXl1JugvDBwDCIEyozlwTGIE 
NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf 
aCebDcMYb/5f jMb/sun4/wnz / xmb8DMA8OxDP9e2L1Ersqco0J-/44DhwG2W 
RAOBYyFS13WpFxY5W3UFNOXLtHYBVR60ggHfVzpBgESk5ZvO0d4PgPSvsFCnW6 
okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik 
MIMuhLBhBq0cydwASBOkIRc3JqzfqHsPP/rVBbRZ2XMWeWY 31Cs8rhBUtHmK 
DTtAyTV5DTeJXYY7£FkOpS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M 
25M13XQa2p 4 9P zEbGf 8 rpvnfseN/F+NbKOnVbO30KSgxOYWMx2cDQdFoDbs 9 
JAAqfZMISjo3yiD5d2vELY/V/0M99V923/5L/b4RtFOUAYhNHFC3t /klygmW 
69g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav 
f1F3zF13Tne/MFt+y8YP91870LyycyX9Rd+fK2CkIZ5tEt 9VTZ+ryY+ULTeqje 
dy0r84pqEbYbr7uvLg0uP21HdoSDyjczp2ay2TP3596cfdikV5lfuz7/0gve 
jU36doy7yL79aisoddj7iQlzuVaVmMLDN/OPcHbuvv8JnZk51eH9E9UaporN 
UPBLo7vfYqU1s7MP587cp8Q0zhdMffOXR9x790aM//-*DtR9/74J0PvvHo*4/-* 
5LRnMN/3jvpQmIl7kx6ZzwSM37YcNylbnbl3jT+VoTOwu8S+vvnwiVcWz+W/ 
NH/6y7/02q+8FZhGS4AQ5SSTuEDWONt YhKO8lexTTHOriVwhWiU3PPXNm7j7t 
/vx/vfcXH/7e73/41Xc/+u33JneMzLNt /+1CSURjjf91lvfF/IfsvHf83avtv 
k9p/55eS10DqmrvdzPTL+M4JCCBIkgTalihppmToVPB7C+vo02Qr1smWSRTbU 
rOSBiveCDqljRK5SmoYZVIS44TjjO305AZzAlZCbTr+IJkvafrAU2f+QVZkOOu 
M1BTJGU7hu/Rzgnz+LP6HQ120i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8 
gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqUNKsOof2FvVUZrFl12DbtR 
40b0rJtznuTSnuHOl1UulBsfGGBdOiyI6PU9/PDff3jy2529Y5vawCAAHyH82 
K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQlwlkaR21/m9TIE75xddtiokHl6nTs 
mN581vZpTzG-*UNgl19j5j36N87WKjORbYJ-8k7C6H/So4ZXrn/omHcUtxL8/n 
INTpu0Hf7uhu+YalxS6AebQ+RuMafkDdQcO7HB+w2cU0O8+doQTRUcpP4J0Kx 
zYplz+MdCq8U/FMEzuDxyNH8al1+/990N4 jidWz jyDwHt 3VY21Aq3Cf1xf/T/ 
2yynd2wF 1GOVA6BjLGz 6PcNfp5RH+eKZrOW5VsfzRy3SvP 9ch3f8ehszeA/7 
C6M4k3dPMTFAi1AI 9bppul EK2EuxFaUQQhRx5wFhmuUIDVRCNKvR4/TOCMZo 
Yo4jh+4p5npgNkwTexwpRBN3PWKYJuY40T7e4vJchCbUyTtxNOF+5rjouUD4 
OFEaQYk8rxiiXJQohkoe/OiFbAIaKQGNmMIAGJaCBCWgSsLQABtMog0lyg0ks 
dHKCPk7QxQl6O0EEHJ-*nfASORr7I1cY5a6MR1207mqgIy9Ubz8W2rB9cCa2THY 
loctxZofxLBT1GO620-*wCwIHz/OTmf5WEtP5vpP5//ERAaRIPIpOBFiOQNg4AX- 
HRAUIgLB71aWcnC9iTTMZXqUIw7010FUEMzJYEKAwGg6qu7Ux5r/QzKL/70B 
3jKbDNqP/6X1XyNpR7P-*ny9x52JQoDsf34Cq/zYjssIDXCypSxrlL/fjUnFZ 
OGdiTgYKkb3iw/rpwn9d+R9//T8K5/81ANL5P8Yd/1/gDHswBP jCvacRXqFK 
LJAD/ANFSzZzIrMPJnZo/k+6ReUPC4058MVLWIpbOll7zi/qzt+p9ySLSr3qci 
VvJPONSkzIooQa2q0HfqIoiUgwwLYfSGxcGOxaQZFml7WvCfAaA7Vv9PhhH/ 
TO7rP0aJ//H2X98Z2YJ/IICzlBLEXA41scqFXNHWr9UYwXEVAUrLKh37hJOFKM 
FSJkFJTLDZjvQxhkCSKlPcfrcFB-*4sNHtZIx7vl/gCRnw/Vf6fwPE-X/HXoy 
HTaVAkTJYMJiqgzbEhY3YcKMAUPisqpVNZgJatl7GTU21MLJEWA41WOm2nuOIOQ 
tatotddxEyOCGfFFsyBKJYUF3iV7'nzdwLrJxHqDXjaZdTjT4pp4n3Mt juVD 
adc0uRo2 9zmr5BLX4bBNOTet LUEQLREVCcd2 zEyGtinTnRp2S+VhgsDA+I8k 
huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve 
+L8e+59+SeV/FO3Gyp211Y0rNy 9OBgLAAQ jQ11IPGeoHIOX/yf8GZ4TZTIWH 
N+njrPmJiNHUKFMPewG4AfIPRYHS/wjKOMKj4M3/JKX6fzRtbWV9ffmyHwCu 
Nmp61Yqs/hvvAQhQpowMvAi qHI 6g8mpOlkTHiypWCciqoKgWBYEQXuDbmxZs 
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VvAdlxIKjgILniUHqGCvqlQ-tdXc/z918rWmT6439i7fvntfnwYZtq7ni3EX2 
ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Dunalr98rXdpWiSméTvLFTXdsqmls7 
SL5wcS4no03du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3 
LOECuUgK6t35N4zta2QDg5vG7g6wXRm8Ll1X0da24s3al9vollxB9d7NcXbtz 
d3O5EAYuzWho2vb5Sbx8uBpaqgij6KxZ4RdqODRLJSUCSCtVRSAtiKVEXMSVgF 
JVHJSUpx6V5tT7hXuyddvyOU7t*6DvRu65BThjXJxOZPpptlbjBHARJstqEVs 
fsUsWapubrOlvExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMIVKRlAAsEaJl 
2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq 
rD/mvZQ690qpYTvEeTXGe5MQQ2qej562vleX4Ganp64Qw7CSHDmoQDxvkHdc 
m7DVOxKdB7x9/PbzL535*pWv/3j6*Asnvv328Qv0p9dOHD8uvAReeP65uc9-* 
6sQvgJe7JMeFt49zlOQXKQnA4ZVAXXQgYvPf*pzU8/f/LE5rpwEnyOfXnxJOMN 
XbNsU8fC58BPSROfOPniOja5q9RJFTALPSN4*mjr5HOUO3RVeBbPs-t*8snuXX2 
ndsgjstdILara+zmCLfcocMvUH3f3T7x4/FvHdk6g4ye7lzfdubzjx5879umv 
fuwd/9F+cuW/b/M/+PA33vmdb33nox/93+e/rd3dKX7zP/7pzB/8o0zRV/ruP 
v3vuz+Y+/tnGv/yD+s7dwg8vv/KjIvfjj5bd30XTv/X5//zDf/61Dz5z/qcz 
bonf+MG77//1dzP/+1fv//1Pfm5+4cTDm+/P/utG7d/++Dv59xalv/2bL//w 
L6997Ws/8+73//3jn+d//eaHb5E//c1Hz8U90J5/VrODT1ljHq/8FCILJvORf 
/6frP401/0s1SR2b+wnHfOJpkN3dtnfjVlulrQjxxit3Tf60k9BiVSXHlolc 
Cl1jSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnIlkhqnjOtHjZ 
OGOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/5PD/9BWv83HvxPsP4n 
ZFjOZPEgL7WDgllgxoc9w/qh4KWQbEmETdQpBwYJyoFRkol9e69MQk-W6OUf 
Z9VP5p/OqRRGIxsqYFrUIXEsc6zr/OEYyP/IXvOHSuV/JK29/jftft*6J1/bu 
MBOmUsxW9tbZ7PyKAiGbx7u7kne6ivfk6H9rlxhOaazl/yKUQvKflv-*PPP9r 
4XqmSEg9Pz/fFXqURWDAOXKGLItU+qIe6PD50K/0pYcHOxRhzKZf+FslugtO 
IH8JgT5jANpjMJUk1V9iOifhTsNyi3i863/IohS2/-*V0/c8Jsvt9*X/W7Ax3 
NcOxaLyvRaOm/21CHFBQzCKXOnAkUJslPTfgoLF9SthoT7rqpaTkJSCBBLCQ 
uNATjmHly6PIEdtkGzeGnABONv97r/4X0/k/R9KGvP5vTkZOKFcgEmDuoJVt 
O2zYEwNoizTFjL5r-*jKF3wlO9vH9WxmqB54157kbl1k2TXDOtprNR1p31UplN 
QWbV8U6D8FQOCIEVaEak/BNpGtCOL2K1515X/l1HY/wdp/mfS5P8g6Y-*VfUXJ 
IQOPHPTb4bA4qEiXs2AbSl1OLukgD8sohuNcJBC3ojKSPkKDViL9R3QF90DfGD 
VzuirOzvikef0DJS+gTYuknjlX8pG43/pfWfT7v85waJvs94IdEPZ3X/v723 
2W3bBt 8L9B2IALsEcUgqRki05c9Fi2LB2a7I169JDgUKXKFVv+oRxSspqctp4H 
7F2G9bjtFZI3Gj9RdiXZ1pN2tZNVbFLHlCjJ9Pf/-«x*29nu2wtSADvXvQBu/ 
Dx5SKVSu-*LQtgNfq/9RckP9Jjf-3BP4XN2AhVQY2ahLpteFqs33eVl1Bh/Seg 
jaNBfx4ITpu2QO1IIFUKogMxw5TkCMOcuMyhmtAQTzxn6vLRGU24GHGWhP7A 
lUAcLMomFKvP-/WbSSBYapTYwFjtmijuMJQORwdaMPluH2Jg4LctpNimxDes]j 
zJjh6p0a9beJ/U*d/ENLEoCim8n9t/9us/8/CFBOzMQ26DL3g7tQONRu7piHOQ 
tl9cvPECO6Ngtk8Xyh2rptanCOlxVRhaYK72BzwbJ3EBAOmxRm5qtFqHYhEQC 
I5//WSQMCtx56EHGQx+STfqcnIV+6MIb4rLEh2sJ6EoSifPGYz9iQt3CdCom 
NrXVIsErvIX7OLaSc05cwdPgXcNWtw2nTESxYGjnCUc/iLCnUFbu3E5fg/Qm 
W8//blkL8T-Elvr/7bL/pO0a*l4tKwOraCeXYOGuUBKosBqRBNTMNOnCQp8iA 
d//e426XTaIsjp*Hp6F3Prft3cApYFjVOWGFog63pQfQRzsCJBsHW67/halW 
Tv5vZvX/mjX+b2KU878P1IfsxF+YOIecNycKKlE9FDOADUCJSariAWZwudQf 
YL/n7DPkL6HgXmFiMuzKVmMcjNkeiNF6LNKU9NITMuhxNZM7VzFwt8fUAXX1 
3BtfuLOqknL789EjJj91-6/19r98/ReN/6RV-/82zf*VZMwfKdUAHAdZesMR 
UohVntWALdzRpF9E4mfuy4Z/JE7c596xgnDczDvA4UjgrIHPelPfy/OLivEHU 
aYpnI/WjBH/E4/EpE2o0lRzpCQJ9F23Nenk4UFHX1FMzVorgfhuhUfbXqa40n 
DKN4I9KXJUzdvi5Pj3Sf1E6auHH37X8RJCBCJq7cYv2HZquE/5ZV2/+3w/8/ 
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rP7vRIX+RTkYHAaDvukOPe6eDYYJ4550pQ+MfwWfviZN4PV14EqLjr/6Sa0i 
VatGrhx4fb9sH/n*GEWOYhlxbBxzDz5R8TEPvzs80jlEkVmxWKk72KeMLzHK 
VLo/sOsEns8ZWyJ6RCKR2+b/Fi7jvO0lxjf8bx3/BxmHEGmo/esuFfoQq+7Gv 
gHhQ1bGT 9wWsvFHR/DCKFULPpCCbDWHTZMSLimMTBdr7aQQrPYdCNqelYNoQQ 
Mx8iiPsCGpqLtYSEUNvJBxcv72Xy/AkYjvlQdseflgKslf9NWsb/203/m8X/ 
kt1Mx8SlozCCpnk6NK6rAX8T2QAZVPI6G2AT4D8mW8Z/Ssr4b5Fa/781/n/A 
8kCe8raSXWnLIXaLzrlO0P4ogYShJkvllYr9CzDJWp7CWqv/980mfcTdiXqNc 
xvE9MzYdnHfwL3Lj1QUnjOtEAn4JzcHaT8M+f308DQL+w8+tWmTMt57/a2Cj 
TP+zDFrXf9vImEn2BGPUQWR316JdZO3uEnT51+Xf60rXq7fq5fLPy3eXfl1lz9 
DnOlqau3V7+hBrr85+qx2bHLd1U2cccu4aRBiemQI qHIgBKaAQ2B6Q/pgDCR 
MM+X3j48rUolXBiMahm43skJqYV6sXZAEWhMWXX7XSwlaFsbj2AsZxjdLE3Ls 
1X1CcOj2tRSsxx0aiQz4dLvxHObLMsrxHOoArOn/hv0/02DKhrlH3b4biIbH 
RbegNGXdvtPe3Dnh8Ail799bvxwdIIQUgOVnakcRMMOGf5Ty-/d8AZ1GUBvt 
PEXPO8n4KRM990rVq52dzPuqs009AQcfLcREwn9w506CI18Dz17jidIQv8QJ 
VaT66S0lsR5dmVaewdiBW+XiSLK20gg9UCen24GA1Wm38VwOnXE76mCZiZ8S 
Nu2QJd+4vDdi3rfM9SDEDCHOEL/PoayXLgKtO+Cxmlk8mLWql+tPlPj6gscy 
dkc/w-*E20jjY210/B2t51664qm6W7rTUYYCy8PWPxAwCEnWf jm42P-*sAzOPd 
qf1h20Z9tiepwfABAhOchpwEWwO4KUJF 9fXqHADIQyoQCJIxgObITABz/fYn1F 
9SfIETkGGO17n1jWvuLucK3sQh21aBaJDBF6igO2d36MQ6VqIBmJgCvw2gHw 
WglY61JqtzWsd2ZhAGom/ZT6mSXYQzx9ygE6U8+09ym9MXt fWOPI3Axrv2AK 
/fwt6/8bEL9r/av3/Dvn/qix9vb70TCNHgDOQG4Apb-* TzMOnJyKTCirE29xVM 
e5QYFZ69a/VAAitCULYdALrORz3qUY/PfPwLCaRGXQDWAAA- 

-— END MESSAGE ARCHIVE -- 
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